Computers have been applied as test computers to test various applications and systems such as websites, object oriented software components, Interactive Voice Response Systems (IVRs) and contact centers.
Virtual web user systems have been provided that are programmed in a variety of ways. For example, an E-test™ virtual web user system from EMPIRIX®, Inc. of Bedford, Mass., can be programmed in Visual Basic. The Visual Basic program can include test scripts that cause the virtual web user system to perform a sequence of tests of the web server. For example, the test scripts can be associated with simulated web user queries to the web server, such as simulated mouse clicks or simulated data entry, for example a name and an address, made by a web user.
Web servers can be tested in a variety of test contexts, and the virtual web user system has been applied to the variety of test contexts. One test context is referred to as functional testing which is defined as the testing generally performed before the web server is released to the public in order to verify that the web server hardware and/or software is functioning properly.
Another test context is known as load testing which is generally defined as the testing generally performed while the web server hardware and software is in public use to verify that the web server hardware and/or software can accommodate at least a certain number of simultaneous web users. Alternatively, the load testing can be performed while the web server is not in public use. In load testing, it is desirable to provide a large number of virtual web users to test the delay time latencies that can be caused by many simultaneous web users.
Yet another test context is known as monitoring testing which is testing that is generally performed while the web server is in public use to verify that the web server hardware and/or software is operational. The monitoring testing may be performed in an automatic background mode wherein the monitoring testing is run at predetermined time intervals to ensure the web server is running properly.
Each of the functional testing, the load testing, and the monitoring testing, has different requirements. For example, a designer of the web server system using a functional test may want to test each possible path through the variety of branching web access options presented to a web user on a web page. In functional testing it may only be necessary to provide a single virtual web user, which exercises, in sequence, most or all of the possible paths through the web page. For another example, a test manager using a load test may want to test only some of the variety of paths through the web page. For yet another example, a test manager using a monitoring test may want to minimally test the general operation of the software application from time to time. In monitoring testing it may only be necessary to provide a single virtual web user, and exercise one or a small number of paths through the web page.
Componentized software is software that is designed to allow different pieces of the application, or “objects”, to be created separately but still to have the objects work together. For this to happen, the objects must have standard interfaces that can be understood and accessed by other objects. The software language enforces some parts of these interfaces. If software interfaces are not directly available as part of the system, a discovery mechanism is employed to find the interface information. If the interfaces are not used, the software objects will not be able to work with other objects. Other practices are imposed by convention. Because these programming practices are known to everyone, the companies that create the containers can rely on them when creating the container. As a result, if these practices are not followed, the container might not operate properly. Thus, there is an indirect mechanism for enforcing these practices.
Test code can be generated by using the attributes of the platform independent language in which the software is written. Using the reflection, a program can determine what are known as the “properties” and “methods” of a bean. The properties of a bean describe the data types and attributes for a variable used in the bean. Every variable used in the bean must have a property associated with it. In this way, the software can automatically determine what methods need to be exercised to test a bean and the variables that need to be generated in order to provide stimulus to the methods.
The methods of a bean describe the functions that bean can perform. Part of the description of the method is the properties of the variables that are inputs or outputs to the method. A second part of the description of each method—which can also be determined through the reflection interface—is the command needed to invoke this method. The detailed description of the method's name, parameters and return value is specified in Remote or Home interfaces and can be also determined with Reflection API available in Java language itself. Because software can determine the code needed to invoke any method and can generate data values suitable to provide as inputs to that method, the software can generate code to call any method in the bean.
Contact centers are known to those of ordinary skill in the art as those systems to which a person can communicate to receive information. Such communication can include, but is not limited to, telephone calls, Internet access, email, and FAX. A contact center can include one or more interactive voice response (IVR) applications, which can be run across one or more IVR systems. The one or more IVRs provide automatic branching voice queries to which the caller responds with button pushes on a telephone keypad or with voice responses on a telephone. The contact center is provided having only the one or more IVR systems, or alternatively, it is also provided having human agents. For example, at the end of the IVR branching voice queries, the caller can be directed to press zero to speak to an agent. The agent is a person having a telephone to talk to the caller, hereafter referred to as an “agent telephone,” and a computer to access information about the caller, hereafter referred to as an “agent computer.” Note that though the agent telephone and the agent computer are often associated with one person, they correspond to distinct electronic systems and will be separately referred to herein.
The contact center can also include one or more database server computers, one or more database storage areas, one or more web server computers, and one or more email server computers. Various testing systems have been provided to test functions associated with the contact center. For example, the HammerIT™ from Empirix, Inc. of Bedford, Mass., can be used to simulate telephone callers in a public switched telephone network (PSTN) having one or more telephone callers who access the contact center either sequentially or in parallel. The HammerIT™ system provides a “virtual telephone caller system” having “virtual telephone callers” that can exercise and test the responses of the one or more IVR systems. The virtual telephone caller system can also be used to test the agent telephone functions of the contact center, providing a “virtual agent telephone system” having “virtual agent telephones.” The virtual telephone caller system can also be used to test FAX functions of the contact center.
Various testing systems have also been provided to test the agent computer function of the contact center. For example, the E-test™ system from the Empirix Inc. can be used to simulate the computer functions of the agent computer, providing a “virtual agent computer system” having “virtual agent computers.” The E-test™ system can also provide a “virtual web user system” having “virtual web users” that include simulations of people who access web pages on a web server within the contact center, people who send/receive email associated with an email server within the contact center, and people who send/receive FAX information associated with a FAX system within the contact center. The virtual telephone caller systems, virtual agent telephone systems, virtual agent computer systems, and virtual web user systems will hereafter be referred to as “virtual test systems.”
Virtual telephone caller systems have been provided that are programmed in a variety of ways. For example, the HammerIT™ virtual telephone caller system described above can be programmed in Hammer Visual Basic. The Hammer Visual Basic program corresponds to a test script that causes the virtual telephone caller system to perform a sequence of programmed tests of the contact center, and in particular, test of the one or more IVR systems within the contact center. For example, the test script can be associated with simulated telephone caller queries to the IVR, such as simulated telephone keypad button pushes or telephone caller voice commands.
Alternatively, a graphical user interface (GUI) can be provided that allows the user to program the virtual telephone caller system using graphical icons that can be connected together in a “call flow diagram.” Such graphic user interfaces provide automatic test generation. For example, the Hammer CallMaster™ software system from Empirix, Inc. of Bedford, Mass., allows the user to interconnect icons on a graphical display, each icon representing an action (or set of actions) to be taken by the virtual telephone caller system, and the interconnections corresponding to a sequence of actions. The call flow diagram results in the automatic generation of the test script described above.
Call flow diagrams are created using a graphical call flow editor in conjunction with a standard library of call flow icons. Each call flow icon is associated with test code necessary to execute the call flow action and an appropriate set of default telephony parameters. These parameters can be overridden on either a global or instance basis. Users can also specify the data to be used in the tests.
Automatic test generation software, is provided, (for example, as part of the Hammer CallMaster™ software system described above), that can exercise the variety of branches through the call flow diagram in a way prescribed by the user. The automatic test generation software eliminates the tedious, unreliable and time-consuming process of manual test design and execution by giving users the power to automatically generate and execute tests derived from a call flow diagram.
By way of the automatic test generation software, test developers create automated tests simply by generating the call flow diagram. Using automatic test generation technology, the software then automatically generates a set of test scripts that are used to exercise all or part of the call flow paths and data in the call flow diagram. Under user control, tests can be generated to do focused testing of a new feature, or general regression testing of the entire application. The same tests can be used for post-deployment monitoring and maintenance to ensure that the application continues to deliver the highest possible level of performance.